-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ACNP appliedto NodePort svc support #3997
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3997 +/- ##
==========================================
+ Coverage 64.45% 67.08% +2.63%
==========================================
Files 294 297 +3
Lines 43726 45846 +2120
==========================================
+ Hits 28184 30758 +2574
+ Misses 13252 12704 -548
- Partials 2290 2384 +94
*This pull request uses carry forward flags. Click here to find out more.
|
Looks like there is a race condition that will cause deadlock. Working on it. Will address @jianjuns 's comments in the same commit. |
a881218
to
0dacb3f
Compare
This pull request introduces 1 alert when merging 0dacb3f into 231b09d - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 0cc328f into 231b09d - view on LGTM.com new alerts:
|
652d2f6
to
8965521
Compare
I'm not against to support IPBlocks as peer only given that we apply this to NodePort Service only which is typically accessed by external network. However, this explanation seems to say it's because of implementation restriction. I don't get why we we not use ct_nw_src for Pod IPs of a normal AddressGroup. |
There are two reasons:
Let me know if I misunderstood something. Other than the implementation reason, I totally agree with you that a NodePort Service is typically accessed by an external network. In-cluster Pods will usually use Service ClusterIP. IMO, supporting |
1 makes sense. 2 is not true. |
700e60a
to
739e7df
Compare
/test-integration |
/test-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM overall
090b3a6
to
8c089ed
Compare
This pull request introduces 1 alert when merging 8c089ed into 98967d7 - view on LGTM.com new alerts:
|
Address comments and add more validation UT cases. Signed-off-by: wgrayson <[email protected]>
Signed-off-by: wgrayson <[email protected]>
/test-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: wgrayson <[email protected]>
/test-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@jianjuns do you have more comments on this one? |
No. |
/test-integration |
/skip-integration tested manually |
Fixes #1580
With this PR users could use ACNP to control the external access of a NodePort Service.
service
field inappliedTo
of ACNP.Service
inAppliedToGroup
and appliedToGroup withService
will span to all Nodes.ipBlock
toct_nw_src
to do source matching.Some API-wise restrictions:
service
in itsappliedTo
.service
field can't be used with other selectors inappliedTo
.ipBlock
can be used to select workloads.appliedTo
like below is invalid:The reason for 3 & 4 is that we use
service
field to decide if a policy or ingress rule is a NodePort Service policy/rule. If it is a NodePort Service policy/rule, we can only usect_nw_src
, transformed fromipBlock
, to do the source matching. The source matching logic is different from normal policy/rule and NodePort Service policy/rule.Signed-off-by: wgrayson [email protected]